「跑得動」跟「看得懂」是兩件事

團隊裡另外兩個系列，一個講怎麼用 Google ADK 把 AI Agent 建出來，一個講怎麼用 GCP Security 視角做紅藍對抗。這個系列要補的是第三塊拼圖：Agent 真的上線之後，你有沒有辦法回答「它剛才為什麼那樣做」？

傳統的應用監控看的是「呼叫了哪個 API、花了多少時間、回傳什麼狀態碼」，這些對一般後端服務已經足夠。但 Agent 不一樣：它會自主決定接下來要呼叫哪個工具、要不要多問一輪、要不要中止任務——同樣的輸入，不保證得到同樣的執行路徑。如果監控系統只停留在「呼叫了哪個 API」這個層次，你看得到動作，看不到為什麼做這個決定。

一個具體的失敗場景

假設一個客服 Agent 某天開始頻繁地把客戶轉接給人工，轉接率從 5% 飆到 40%。傳統監控只會告訴你「轉接次數變多了」，但真正該回答的問題是：**是哪一類問題觸發轉接？Agent 的推理過程在哪一步判斷「這個我處理不了」？是模型變得更保守，還是某個上游工具開始回傳異常資料，讓 Agent 誤判？**沒有決策鏈路的可觀測性，這些問題只能靠工程師憑經驗猜，猜錯了就是白工。

這個系列要建立的能力

30 天會用 Google Cloud 的可觀測性工具鏈，把「Agent 內部發生了什麼」變成看得見、可追溯、可查詢的資訊：

跟另外兩個系列的關係

這系列刻意設計成可以獨立閱讀，但如果你也在追團隊另外兩個系列，會發現三者剛好構成完整的產品生命週期：ADK 系列教你怎麼「建」，Agentic AI 攻防系列教你怎麼「打」與「防」，這個系列教你上線後怎麼「看」。Google Cloud Trace 甚至對 ADK 應用有內建的 OpenTelemetry 整合，這點 Week 3 會展開細講——等於你用 ADK 建的 Agent，可觀測性有一部分是官方直接幫你接好的。

讀者會帶走什麼

五週各留一份可直接用的產出：可觀測性成熟度自評表、結構化日誌 Checklist、決策鏈路追蹤範本、告警規則與 Dashboard 範本，最後收斂成一套從監控到稽核治理的完整方法論。

明天先建立共同語言：可觀測性的三支柱，在 Agent 場景下該怎麼重新理解。

💡 關於作者 我是 Fngi，專注在 AI 安全與雲端資安領域。如果這篇對你有幫助，歡迎追蹤 Instagram @aid3fend，我在那裡分享更多 AI 資安的實務筆記與趨勢觀察。